Changement de licence open source : comment s’en prémunir
Le changement de politique d’Elastic provoque des remous dans la communauté open source. Mais les usagers, qu’ils soient des organisations, des développeurs, ou des amateurs chevronnés, veulent éviter ce type de situation. En réalité, le choix de la licence compte autant que le mode de distribution de la propriété intellectuelle entre les contributeurs.
Si le changement de licence d’Elasticsearch inquiète les startups qui éditent des solutions SaaS, elle peut également poser question pour les entreprises utilisatrices. Pour le moment, les modifications de produits Elastic ne suscitent pas réellement de gêne à ce niveau-là. Les organisations adeptes de la distribution sous licence Apache 2.0 (jusqu’à la 7.10 inclus), maintiennent leurs usages et aviseront quant à l’adoption d’une version bifurquée à l’avenir.
Ces technologies ouvertes favorisent une standardisation des déploiements et réduisent la portion de développement en interne. Alors, comment s’assurer de choisir le bon projet ? Le plus souvent, les performances et la stabilité du code priment. Mais la pérennité d’un projet open source se joue également dans le choix de la licence et dans le mode de partage de la propriété intellectuelle auprès des contributeurs.
« Il n’y a pas une seule réponse sur la manière d’évaluer une licence open source », considère Philippe Ombrédanne, CTO de nexB une société spécialisée dans l’audit de logiciels tiers et open source. « Il y a essentiellement deux écoles, l’une portée par la Free Software Foundation et l’autre par l’Open Source Initiative. La première vérifie si un projet logiciel est libre ou non libre, s’il est en accord avec les licences GNU GPL, LGPL et FDL. De son côté, l’OSI examine si les licences sont en accord avec sa définition de l’open source ».
Cette définition d’une licence open source dictée par l’OSI tient en dix points :
Elle autorise la redistribution libre du projet
Le programme associé doit inclure le code source
La licence doit permettre des travaux dérivés
Elle garantit l’intégrité du code source (ou des marques) de l’auteur
Elle interdit toute discrimination contre des personnes ou des groupes
Elle interdit toute discrimination contre des utilisations spécifiques du code ou projet
Elle offre une autorisation unique pour tous les droits de licence
La licence ne doit pas être spécifique à un produit
Elle ne doit pas restreindre d’autres logiciels
La licence doit être technologiquement neutre
« Ce processus dépend d’un cérémoniel particulier. Au sein de l’OSI, nous avons des volontaires experts qui observent les licences et qui discutent avec le soumettant, afin de déterminer le respect de ces critères des logiciels ouverts », ajoute-t-il.
Elastic se retrouve sur le devant de la scène, mais son choix de la licence SSPL fait suite à la décision de MongoDB de créer ce référentiel en altérant le modèle GNU Affero (plus spécifiquement l’AGPVLv3). « La SSPL modifie la section 13 de la licence Affero qui empêche son utilisation d’un projet en mode SaaS. C’est véritablement une restriction d’usage pour une certaine catégorie d’utilisateurs. Or les critères de l’OSI et de la FSF déterminent qu’il n’y a pas de restriction sur les champs d’utilisation d’une licence libre », indique Philippe Ombrédanne. « C’est un thème qui va revenir régulièrement, que ce soit pour des notions commerciales ou éthiques », ajoute-t-il. « Mais il n’y a pas d’ambiguïté sur la licence SSPL et elle est considérée comme propriétaire ».
Il existe plus de 1 700 licences open source, selon le spécialiste. Seule une vingtaine d’entre elles sont employées massivement. GPLv2, GPLv3, LGPL, Apache 2.0, MIT (attention aux variantes), BSD ou encore Eclipse 1.0, font partie des licences les plus populaires. Les projets qui les portent sont donc plus faciles à appréhender, par ce que l’on évoque là des standards bien connus. Mais au moment de choisir d’employer un logiciel open source, le CTO de nexB considère qu’il faut aussi et surtout se pencher sur la distribution de la propriété intellectuelle parmi les contributeurs.
CLA vs DCO, un vieux débat
« Il y a deux types de projets open source. Des projets qui demandent la cession des droits des propriétés intellectuelles et ceux qui ne le demandent pas. Dans le premier cas, vous signez un document et effectivement l’éditeur ou l’auteur ou l’organisation va pouvoir changer la licence à gré, sans aucune contrainte. C’est pour moi un drapeau rouge majeur. Si le contributeur principal a la possibilité de modifier la licence, il le fera. MongoDB et Elastic peuvent être considérés comme des cas d’école en la matière », remarque-t-il.
L’assignation des droits dépend souvent d’un document nommé Contribution License Agreement (CLA). Les contributeurs l’émargent avant toute première contribution originale. Ce CLA correspond à un engagement entre l’auteur du code et le responsable du projet. Dans le cas d’Elasticsearch, jusqu’à la version 7.10, les contributeurs devaient autoriser la distribution de leur code sans restriction, mais ils en restaient propriétaires. L’accord se jouait entre le contributeur et Elastic. Pour « changer de licence », Elastic a lui-même forké son projet tout en conservant l’appellation Elasticsearch dont il possède les droits.
Dans d’autres cas, le CLA peut être encore plus restrictif et imposer un don sans condition des contributions.
Vérifier le modèle d’assignation des droits
En réalité, tout se joue dans la relation entre le signataire et le responsable du projet. Quand le mainteneur du projet est une fondation, le risque de modification de licence en cours de route s’avère bien plus faible. Prenons un exemple ô combien populaire : Kubernetes. L’orchestrateur de container est distribué sous licence Apache 2.0, associée à un CLA, mais ces deux documents sont attribués à la Cloud Native Computing Foundation, un projet de la fondation Linux. « L’attribution des droits du code à une organisation, et plus spécifiquement à une ONG, limite les risques de changement de licence », estime Philippe Ombrédanne. « C’est le cas de la Fondation Apache qui demande pour certains projets l’assignation des droits en son nom. C’est une ONG avec plus de vingt ans de pratique. La fondation Eclipse, par exemple, qui a un modèle de gouvernance très fort, propose son propre modèle de licence comme Apache, mais ne demande pas la cession des copyrights ».
Cependant, il existe un modèle plus vertueux et moins risqué, selon lui.
« Quand il n’y a pas d’assignation des droits, les contributions peuvent s’accumuler jusqu’à un niveau de diffusion des copyrights auprès de l’ensemble des contributeurs. Quelle que soit la licence, ce mode-là offre la garantie de pérennité du projet open source, peu importe s’il est orchestré par une entité commerciale ou non. Cela sera très compliqué de changer les conditions de la licence, car il faut l’assentiment de la majorité sinon la totalité des contributeurs », affirme Philippe Ombrédanne.
Le CTO de nexB cite l’exemple d’OpenSSL. Le projet dépendait d’une licence propre dérivée du modèle BSD. En 2015, la fondation éponyme a annoncé sa volonté d’adopter la licence Apache 2.0. Elle a dû lancer une campagne email auprès de plus de 400 contributeurs. Cela a pris près de trois ans. Philippe Ombrédanne évoque également le cas de ZeroMQ, une bibliothèque de messagerie asynchrone dont le changement de licence LGPL-v3 à MPLv2 a été lourdement freiné (aussi parce que le contributeur principal, un Benevolant Dictator for life a péri entretemps).
« C’est un processus long, douloureux. Plus le temps passe, plus cette affirmation est vraie. Si des contributeurs décèdent, comment faites-vous pour obtenir leur assentiment ? Vous allez voir leurs héritiers ? C’est un vrai panier de crabes, mais un panier de crabes sain. Il n’y a rien de pire qu’un projet qui change de licence, parce que c’est un véritable problème pour les utilisateurs ».
« Les critères de qualité, de maintenabilité, de dynamisme de la communauté sont importants, mais concernant les licences c’est selon moi la chose principale à retenir : il faut des copyrights distribués ».
Philippe OmbrédanneCTO de nexB
Cette traçabilité des contributions est un sujet bien connu des participants au code du noyau Linux. Pour faciliter cette gestion, Linux a introduit en 2004 le Developer Certificate of Origin. « Le DCO est explicitement agréé par l’ensemble des contributeurs Linux, ce qui revient à accepter que le code que je donne à Linux soit quelque chose dont j’ai les droits, qui est ma contribution originale, et cela garantit une traçabilité des contributions », déclare Philippe Ombrédanne. « Mais aujourd’hui avec les systèmes de gestion de versions comme Git, ce processus est quasiment automatique ».
« Les critères de qualité, de maintenabilité, de dynamisme de la communauté sont importants, mais concernant les licences c’est selon moi la chose principale à retenir : il faut des copyrights distribués ».
Une licence, plusieurs modèles d’assignation des droits
Rappelons que cette notion de propriété intellectuelle distribuée est indépendante de la licence open source choisie par le mainteneur d’un programme libre. Reprenons notre exemple de Kubernetes. Il fait presque office d’exception dans le fonctionnement de la CNCF et plus largement de la fondation Linux. Parce qu’il s’agit d’une organisation ombrelle, chaque contributeur principal de projets désigne sa licence et son mode de distribution des droits. Par exemple, les projets Helm et le service Mesh Linkerd sont tous deux sous licence Apache 2.0, mais leurs comités de pilotage ont décidé d’employer un DCO. À l’inverse, CouchDB, une base de données présente dans la liste de la CNCF dépend surtout de la fondation Apache qui applique un CLA dont elle est la responsable.
Contribuer aux projets open source, un moyen sûr d’assurer son avenir
« Beaucoup de grandes entreprises veulent adopter l’open source, mais souhaitent obtenir le support d’un acteur commercial. C’est une façon de voir les choses. Ce que les gens ne comprennent pas, c’est qu’avoir un acteur commercial par-dessus un projet communautaire, offre une garantie de moyens, mais pas de résultat. Il y a des approches alternatives qui consistent à s’assurer que le projet open source soit sain, d’opérer des feedbacks sur la qualité d’un projet, de contribuer à des projets, même le simple signalement de bug est très utile », considère Philippe Ombrédanne.
Cela n’empêche pas de se tourner vers une distribution commerciale, mais réaliser des contributions permet d’enrichir le produit open source. Si par malheur les relations avec l’éditeur se gâtent, il sera plus facile de reprendre la gestion des éléments soi-même ou de passer le relais à un autre acteur capable de s’appuyer sur le code source ouvert.
Certifier l’origine du code
Au-delà de cette question de distribution des droits qui peuvent influencer la portabilité et l’interopérabilité d’un logiciel open source, les entreprises doivent également gouverner leur adoption de multiples projets open source.
« Imaginez que vous êtes un fabricant de voitures. Vous n’êtes pas capables de me dire où vous avez acheté le carburateur, vous n’êtes pas trop sûr de la provenance du système de frein et vous vous rappelez vaguement d’où viennent les ceintures de sécurité. C’est un peu ce qu’il se passe avec l’open source aujourd’hui. C’est tellement facile de télécharger et d’installer des logiciels open source, les gens ne savent plus ce qu’ils ont. Vous installez un package et d’un seul coup vous en avez 300 qui viennent avec, à cause des dépendances. Mais c’est important de savoir ce que vous utilisez ».
« Vous installez un package [open source] et d’un seul coup vous en avez 300 qui viennent avec, à cause des dépendances. Mais c’est important de savoir ce que vous utilisez ».
Philippe OmbrédanneCTO, nexB
Cela peut avoir des conséquences graves quand un composant open source n’est pas mis à jour, par exemple des problèmes de cybersécurité. Il est également possible que parmi ces outils se cachent des éléments de code propriétaire.
« Les audits ne sont pas forcément nécessaires. L’on peut automatiser la traçabilité du code que l’on utilise, archiver systématiquement les sources et les binaires. Si l’on part de zéro, il faut connaître l’origine du code et donc opérer à un audit. C’est un problème beaucoup plus complexe qu’il n’y paraît et tout n’est pas encore automatisable », déclare Philippe Ombrédanne.
« Aujourd’hui, nous observons des situations courantes où 5 000, voire 10 000 composants open source externes sont intégrés à des applications d’entreprise. Cela demande une discipline de fer pour ne pas se laisser submerger », prévient-il.
NexB propose une solution pour automatiser la gestion des logiciels open source et assurer la conformité du code à la licence associé. Philippe Ombrédanne est également le cofondateur du projet SPDX, un format de fichiers pour documenter des informations sur les licences de logiciels. Il participe au projet ClearlyDefined, mené par Microsoft et l’Open Source Initiative, dont le but est de clarifier l’origine du code source de logiciels libres et les licences associées, d’en supprimer les vulnérabilités et les bugs.
